Add build step to CI - #410

Features and Changes

Adds a Build GitHub Actions workflow (.github/workflows/build.yml) that runs pnpm build on every pull request and on pushes to main.

Until now the only CI we had was the Prettier/Lint workflow, which means a PR could be merged with code that doesn't compile — formatting was checked, but nothing ever verified that the Next.js app actually builds. This closes that gap so build breakages are caught in review instead of at deploy time.

Details worth calling out:

• Environment mirrors the Lint workflow. Same actions/checkout@v4, pnpm/action-setup@v4.0.0 pinned to pnpm 10.14.0, so both workflows stay in sync. Adds actions/setup-node@v4 on Node 20 with cache: pnpm to keep installs fast.
• pnpm install --frozen-lockfile instead of a bare pnpm install, so CI fails loudly if pnpm-lock.yaml is out of date rather than silently resolving something different from what we committed.
• Placeholder env vars. pnpm build runs prisma generate && next build, and several modules construct their clients (Prisma, Supabase, Mailgun, Notion) at import time. Those clients need the variables to be present and well-formed — a malformed DATABASE_URL fails Prisma's URL parsing, for example — so the job defines dummy values. Nothing in this list is a real credential and no external service is contacted during the build; the comment in the file says as much so nobody mistakes them for secrets that need rotating.
• Concurrency group on github.ref with cancel-in-progress: true, so pushing several commits to a PR in quick succession cancels the stale builds instead of queueing them all.

Screenshots / Screen Recordings

N/A — CI-only change, no UI surface.

Testing your changes

The workflow triggers on pull_request, so opening this PR is itself the test: the Build / Next.js build check on this PR is the first real run, and it needs to go green before this merges.

Steps on how to test your changes

1. Look at the Checks tab on this PR and confirm Build / Next.js build passes.
2. To confirm it actually catches breakage, push a commit to this branch that introduces a type error or a bad import, and verify the check goes red — then revert it.
3. To reproduce the CI environment locally, export the same placeholder values listed in build.yml and run pnpm install --frozen-lockfile && pnpm build.

Other Notes

• The build is not yet a required status check — that has to be configured in the repo's branch protection settings for main before it can actually block a merge. Worth doing as a follow-up, otherwise this is advisory only.
• Only the build is covered here. Type checking beyond what next build does, pnpm lint (ESLint), and tests are not wired into CI. The existing Lint workflow only runs Prettier. Those are natural follow-ups but felt out of scope for a first build step.
• The placeholder env vars are duplicated inline in the workflow. If the app grows more import-time clients, this list has to be updated by hand or the build will start failing for reasons unrelated to the PR being tested. If that becomes annoying we could move to a committed .env.ci file instead.
• Node is pinned to 20 here. If we want to match whatever the deploy target runs, happy to bump it — just let me know what that is.